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ABSTRACT 

Thousands  of  small  UAVs  are  in  active  use  by  the  US  military  and  are  generally  operated  by  trained  but  not  necessarily 
skilled  personnel.  The  user  interfaces  for  these  devices  often  seem  to  be  more  engineering -focused  than  usability- 
focused,  which  can  lead  to  operator  frustration,  poor  mission  effectiveness,  reduced  situational  awareness,  and 
sometimes  loss  of  the  vehicle.  In  addition,  coordinated  control  of  both  air  and  ground  vehicles  is  a  frequently  desired 
objective,  usually  with  the  intent  of  increasing  situational  awareness  for  the  ground  vehicle.  The  Space  and  Naval 
Warfare  Systems  Center  Pacific  (SSCPAC)  is  working  under  a  Naval  Innovative  Science  and  Engineering  project  to 
address  these  topics.  The  UAS  currently  targeted  are  the  Raven/Puma/Wasp  family  of  air  vehicles  as  they  are  small,  all 
share  the  same  communications  protocol,  and  are  in  wide-spread  use.  The  stock  ground  control  station  (GCS)  consists  of 
a  hand  control  unit,  radio,  interconnect  hub,  and  laptop.  The  system  has  been  simplified  to  an  X-box  controller,  radio  and 
a  laptop,  resulting  in  a  smaller  hardware  footprint,  but  most  importantly  the  number  of  personnel  required  to  operate  the 
system  has  been  reduced  from  two  to  one.  The  stock  displays,  including  video  with  text  overlay  on  one  and  FalconView 
on  the  other,  are  replaced  with  a  single,  graphics -based,  integrated  user  interface,  providing  the  user  with  much 
improved  situational  awareness.  The  SSCPAC  government-developed  GCS  (the  Multi-robot  Operator  Control  Unit) 
already  has  the  ability  to  control  ground  robots  and  this  is  leveraged  to  realize  simultaneous  multi -vehicle  operations 
including  autonomous  UAV  over-watch  for  enhanced  UGV  situational  awareness. 
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1.  INTRODUCTION 

Tactical  UAVs  such  as  the  Raven,  Puma  and  Wasp  are  often  used  by  dismounted  warfighters  on  missions  that  require  a 
high  degree  of  mobility  by  the  operators  on  the  ground.  The  current  ground  control  stations  (GCS)  for  the  Wasp,  Raven 
and  Puma  tactical  UAVs  require  two  people  and  two  user  interfaces  -  one  for  basic  control  of  the  aircraft  from  an 
airborne  camera  perspective  and  the  other  using  a  third-party  map  display.  Typical  in-theater  usage  is  shown  in  Figure  1, 
the  data  displayed  on  the  interfaces  is  shown  in  Figure  2. 


Figure  1.  Two  operators  controlling  a  Raven  RQ-11.  The  laptop  is  used  for  map-based  control  while  the  hand 
controller  is  used  for  manual  control.  Photo  courtesy  of  John  Moore/Getty  Images 
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Figure  2.  The  actual  displays  of  the  laptop  and  hand  controller. 

For  the  stock  GCS,  the  vehicle  operator  (VO)  uses  the  hand  controller  for  launching  and  various  manual  control  modes. 
The  hand  controller  displays  live  video  from  the  aircraft  with  block  text  overlays.  More  detailed  control  is  possible  via 
text-based  menus.  The  mission  operator  (MO)  uses  the  laptop  for  map-based  control  of  the  vehicle,  limited  to  setting 
parameters  of  the  various  waypoints  (the  waypoints  are  labeled  A,  B,  C,  D,  E,  L  Ol,  02,  03  and  H).  The  VO  has  no  map 
display  (video  only)  but  has  full  control  of  the  vehicle.  The  MO  can  display  the  live  video  but  cannot  control  the  vehicle 
in  any  mode  other  than  NAV  mode,  which  is  used  for  waypoint  control. 

2.  STOCK  GCS 

While  it  is  possible  for  an  operator  to  complete  a  mission  single-handedly  the  preferred  mode  of  operation  uses  two 
operators.  As  has  been  documented  in  many  publications 1’2,3-4  coordinated  control  of  a  UAS  with  multiple  operators  is 
difficult  and  can  be  the  source  of  mishaps  resulting  in  damage  to  or  loss  of  the  UAV.  While  the  Raven,  Puma  and  Wasp 
UAVs  are  much  simpler  and  easier  to  operate  than  those  identified  in  the  cited  works,  the  issues  of  coordinated  control 
are  still  applicable.  In  addition,  the  existing  GCS,  while  relatively  easy  to  use,  presents  several  challenges  from  a  user 
interface  perspective.  Pamranky5  found  that  during  a  typical  ~43  minute  mission  there  were  over  a  thousand  instances 
where  the  operator  was  subjected  to  high  workloads. 

2.1  Situational  Awareness 

Manning4  notes  that  situational  awareness  is  a  leading  causal  factor  in  mishaps.  For  the  stock  GCS  there  are  several 
detriments  to  situational  awareness: 

•  The  lack  of  a  map  display  for  the  VO.  The  VO  rarely  knows  the  location  of  the  vehicle  on  a  map,  which  is 
invaluable  in  determining  not  only  where  the  vehicle  is  but  also  potential  hazards  to  the  UAV. 

•  Poor  heading  display  (usually  displayed  as  a  number  rather  than  as  a  compass  rose,  though  a  blocky  compass 
can  be  overlaid  on  the  video). 

•  Poor  or  non-existent  altitude  above  ground  level  (AGL)  display.  This  is  important  for  mission  effectiveness  as 
well  as  vehicle  safety.  AGL  altitude  can  be  displayed  on  the  MO  screen  by  displaying  the  Mission  Altitude 
Control  Screen  and  clicking  on  a  waypoint,  at  which  point  the  AGL  altitude  for  that  waypoint  will  be  displayed 
for  3  seconds. 


•  Disorientation  when  switching  view  from  the  handheld  controller.  The  display  on  the  handheld  controller  is 
relatively  dim  so  a  hood  is  necessary  during  daylight.  Whenever  the  VO  needs  to  “de-hood”  the  change  in 
brightness  causes  loss  of  vision  for  5-15  seconds.  This  disorientation  period  could  be  crucial  if  the  UAV  is 
being  brought  in  for  a  manual  landing  or  if  the  VO  needs  to  move  quickly  due  to  a  developing  situation. 

2.2  Hardware 

The  stock  GCS  hardware  is  fairly  compact  considering  it  is  intended  to  be  used  by  two  operators.  However,  there  are 
some  issues  with  the  hand  controller  hardware: 


•  As  mentioned  above  the  display  screen  on  the  hand  controller  requires  a  hood  when  used  in  daylight  conditions 
as  the  screen  is  too  dim  to  be  used  otherwise. 

•  Conversely,  the  hand  controller  screen  is  not  night  vision  goggle  (NVG)  compatible,  so  night  time  operations 
where  NVGs  are  used  become  awkward  in  a  way  similar  to  the  problems  with  daytime  use. 

•  Video  latency  is  about  400  milliseconds.  This  is  adequate,  but  our  own  tests  have  shown  that  this  can  be 
reduced  by  at  least  a  factor  of  two.  This  could  make  some  control  operations  such  as  camera  orientation  over  a 
desired  point  much  easier  to  achieve. 

•  The  majority  of  GCS  hardware  is  vehicle  specific  and  cannot  be  used  to  control  other  vehicles  or  used  for  any 
other  purpose.  In  addition,  upgrading  or  replacing  the  GCS  with  more  modern  hardware  would  be  difficult  or 
impossible. 

2.3  User  Interface:  Hand  Controller 


The  hand  controller  for  the  stock  GCS  (shown  in  Figure  2)  is  a  relatively  simple  device  consisting  of  a  video  screen  with 
text  overlays,  a  joystick,  a  toggle  switch,  a  four-way  “hat”  control  and  four  buttons  (two  on  the  front  and  two  on  the 
back).  The  display  in  particular  is  a  very  simple  device;  it  just  displays  video  from  the  UAV  with  textual  overlays  to 
display  data  and  implement  menus.  It  has  neither  a  touch  screen  capability  nor  any  kind  of  pointing  device  such  as  a 
mouse. 
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•  Because  of  the  limited  display  room,  resolution  and  graphics  capability,  the  textual  displays  can  be  cryptic.  For 
example,  the  standard  display  screen  has  four  different  textual  fields  indicating  angular  measurements  for 
magnetic  heading,  direction  from  the  home  waypoint  to  the  UAV,  wind  direction,  and  target  bearing,  none  of 
which  are  labeled.  A  trained  operator  could  discern  the  meaning  of  each  of  these  fields  from  surrounding 
context  but  being  able  to  immediately  find  the  desired  information  requires  more  cognitive  effort  than  is 
desirable. 


•  Camera  selection  and  zooming  is  awkward.  A  shift  key  on  the  left  side  of  the  back  of  the  hand  controller  must 
be  held  in  to  bring  up  a  camera  menu.  The  menu  select  four-way  switch  (also  on  the  left  side)  is  then  used  to 
select  a  camera  (front  or  left)  as  well  as  zoom.  The  zoom  selection  (there  are  four  fixed  levels)  is  different 
depending  on  which  camera  you  are  zooming.  For  the  left  camera  moving  the  control  left  cycles  through  the 
zoom  levels  in  a  fixed  order.  For  the  front  camera  moving  the  control  up  cycles  through  the  levels.  The  down 
and  left  motions  of  the  control  change  the  camera  filters  or  turn  the  cameras  off. 

•  Initial  loiter  mode  selection  requires  four  button  clicks  to  engage,  which  often  results  in  the  desired  loiter  point 
not  being  achieved.  Fortunately,  re-establishing  a  loiter  point  while  in  loiter  mode  can  be  done  by  double¬ 
clicking  the  Enter  button.  However,  it  is  unclear  which  location  the  vehicle  is  attempting  to  loiter  around  since 
there  is  no  graphic  overlay  to  display  this  information  on  the  handheld  unit. 

•  The  wind  indicator  is  a  simple  numeric  angle  and  speed.  It  is  crucial  when  using  automated  landing  that  the 
final  approach  segment  be  aligned  into  the  wind.  The  landing  direction  is  established  by  the  E  and  L  waypoints 
and  must  be  positioned  such  that  going  from  E  to  L  results  in  the  vehicle  heading  directly  into  the  wind. 
Crosswind  or  downwind  landings  can  result  in  damage  to  the  aircraft  as  well  as  poor  touchdown  point 


performance.  Unfortunately,  it  is  difficult  to  translate  the  numeric  value  for  wind  direction  into  the  graphical 
representation  of  the  E  and  L  waypoints,  which  increases  the  likelihood  of  creating  an  incorrect  landing  plan. 

2.4  User  Interface:  Laptop 

The  laptop  runs  the  DoD  FalconView  program.  This  is  connected  to  the  GCS  via  an  Ethernet  cable  that  provides  status 
information  and  video  as  well  as  limited  control  of  the  vehicle.  The  FalconView  application  was  never  intended  to  be 
used  for  vehicle  control  (it  is  primarily  a  map  display  and  mission  planning  application),  and  as  a  result  there  are  several 
usability  issues: 

•  The  MO  (via  FalconView)  can  only  control  the  vehicle  when  it  is  in  NAV  (waypoint)  mode.  When  the  MO 
moves  a  waypoint  a  message  is  displayed  indicating  that  the  UAV  is  being  re-routed.  This  message  remains  for 
a  few  seconds  then  disappears.  However,  if  the  vehicle  isn’t  currently  in  NAV  mode  the  command  will  have  no 
effect,  but  no  error  message  will  be  displayed.  The  MO  must  first  verify  that  the  vehicle  is  in  NAV  mode  via  a 
dense  text  display  in  the  lower  left  corner  of  the  map  to  ensure  that  the  change  will  have  an  effect.  The  VO  can 
change  modes  at  any  time  and  the  MO  is  not  notified  other  than  the  text  display  in  the  lower  left  corner. 

•  The  graphical  heading  displayed  via  an  icon  on  the  map  shows  the  course  heading  of  the  vehicle  while  the 
textual  heading  on  the  hand  controller  shows  magnetic  heading.  These  differences  are  often  significant  and  are 
exacerbated  by  windy  conditions. 

•  Waypoint  altitudes  can  be  adjusted  numerically  or  graphically  in  two  different  dialogs.  For  maximum  mission 
duration  the  mean  sea  level  (MSL)  altitude  should  be  the  same  for  all  waypoints,  subject  to  mission  constraints. 
However,  there  is  no  easy  way  to  force  all  the  waypoints  to  the  same  MSL  altitude,  and  in  fact  it  is  quite  easy  to 
inadvertently  change  the  altitudes  of  the  waypoints  during  other  mission  planning  operations. 

•  On  the  graphical  waypoint  altitude  dialog  the  textual  altitudes  are  only  displayed  when  the  user  clicks  on  a 
waypoint  and  moves  it.  This  has  the  side-effect  of  changing  the  altitude  of  the  waypoint  which  may  not  be 
desired. 

•  The  above  ground  level  (AGL)  altitude  can  only  be  displayed  on  the  graphical  dialog  and  is  only  displayed  for  a 
single  waypoint  at  a  time,  and  even  then  only  for  three  seconds.  As  with  the  MSL  altitude,  the  operator  must 
first  move  a  waypoint  before  the  AGL  for  that  waypoint  will  be  displayed. 

•  In  all  modes  except  NAV  mode  the  current  altitude  can  easily  be  increased  or  decreased  with  the  throttle 
control. 


3.  MULTI-ROBOT  OPERATOR  CONTROL  UNIT 

All  of  the  shortcomings  of  the  current  GCS  can  be  addressed  using  a  laptop-based  GCS  with  the  appropriate  software. 
The  Space  and  Naval  Warfare  Systems  Center  Pacific  has  been  developing  the  Multi-robot  Operator  Control  Unit 
(MOCU)  software  since  2001  with  the  intent  of  making  it  of  use  on  any  robotic  system  regardless  of  the  domain  in 
which  the  robot  operates. 

MOCU  was  designed  to  be  completely  modular.  This  is  especially  true  for  the  user  interface.  As  described  in  Powell7, 
MOCU  was  designed  in  particular  to  focus  on  making  the  user  interface  as  flexible  and  programmable  as  possible,  with 
an  eye  toward  developing  game-like  interfaces  that  current  and  future  unmanned  vehicle  operators  will  be  accustomed 
to.  The  rest  of  this  paper  describes  how  MOCU  was  used  to  implement  a  better  user  interface  to  the  Raven-class  of 
UAVs. 

In  this  instantiation  of  MOCU  a  ruggedized  laptop  (similar  to  that  of  the  stock  GCS)  is  used,  but  the  hand  controller  has 
been  replaced  with  an  Xbox  360  gamepad,  something  the  operators  are  likely  to  already  be  very  familiar  with.  The  stock 
GCS  radio  is  used,  however  the  “hub”  is  not  needed,  thus  saving  significant  weight  and  reducing  complexity. 

3.1  Single  screen,  single  operator 

The  first  task  in  improving  the  user  interface  was  to  put  all  the  functionality  onto  a  single  screen.  This  means  the  display 
must  be  able  to  show  both  live  video  from  the  UAV  as  well  as  maps  and  map-related  data.  The  screen  shown  in  Figure  3 
illustrates  the  how  the  video  is  displayed.  The  video  is  the  background  for  the  data  on  the  display  (more  on  that  below). 
Starting  with  the  left  side,  going  from  top  to  bottom,  there  are  indicators  for  current  mode  (MAN  indicates  manual 


mode),  camera  selection  and  zoom  level  (left  camera,  narrow,  meaning  next  to  highest  zoom  level),  and  an  altitude  tape, 
with  the  vehicle’s  current  altitude  shown  in  the  black  box  with  white  text.  Because  a  touchscreen  is  used  the  mode  and 
camera  indicators  can  also  be  touched  to  bring  up  menus  to  select  different  modes  or  cameras.  This  means  that  at  most 
two  actions  are  required  to  change  either  the  UAV  mode  or  the  camera  and  zoom  level. 

The  upper  right  corner  of  the  display  shows  the  vehicle  battery  and  communications  status.  On  the  stock  GCS  the 
operator  must  memorize  critical  voltage  levels  to  recognize  when  the  battery  is  getting  low,  while  MOCU  uses  a 
graphical  icon  very  similar  to  what  users  are  accustomed  to  seeing  on  their  cell  phones.  This  area  of  the  display  is  also 
used  for  bringing  up  more  detailed  menus  (the  gear  icon)  as  well  as  a  map  orientation  indicator  (the  map  will  have  the 
ability  to  be  rotated  arbitrarily  to  make  situational  awareness  easier).  Along  the  right  edge  is  an  airspeed  tape  as  well  as  a 
graphical  indicator  depicting  throttle  setting  (only  shown  for  3  sec.  after  a  throttle  change). 


Figure  3.  MOCU  screenshot  showing  how  video  is  displayed. 

The  A,  B,  C,  D,  E,  and  L  icons  are  the  pre -defined  waypoints  while  the  1,  2  and  3  icons  with  the  circles  are  the  orbit 
waypoints.  The  plane-like  icon  represents  the  position  and  orientation  of  the  vehicle  itself.  Note  that  these  are  all  map¬ 
centric  not  video-centric  (this  will  be  explained  below).  Finally,  there  is  a  red  shading  over  most  of  the  display.  This  is  a 
profile  of  the  elevation  directly  in  front  of  the  vehicle.  This  is  a  safety -related  feature  unique  to  MOCU.  Under  normal 
(safe)  flight  operations  the  red  area  is  not  visible;  it  only  becomes  visible  when  there  is  a  potential  terrain  conflict.  In  this 
particular  case  the  vehicle  was  pointed  toward  a  hill  and  if  the  vehicle  were  to  fly  in  that  direction  without  an  increase  in 
altitude  it  would  contact  the  ground. 

Figure  4  shows  virtually  the  same  screenshot,  but  with  the  background  changed  to  show  the  map.  The  vehicle  icon  and 
the  various  waypoints  now  make  a  little  more  sense  since  they  are  directly  related  to  the  map.  The  important  user 
interface  feature  to  point  out  here  is  that  the  same  waypoint  and  vehicle  location  data  is  present  both  on  the  map  and  on 
the  video,  so  that  when  the  user  toggles  between  the  two  screens  these  icons  remain  in  the  same  location.  This  gives  the 


operator  better  situational  awareness  for  where  the  vehicle  is  relative  to  the  GCS  and  the  waypoints,  while  still 
displaying  the  video,  which  is  used  more  frequently  by  the  operator  during  a  mission  than  the  map. 


The  screen  of  the  laptop  is  sufficiently  bright  alleviating  the  need  for  a  hood,  thus  taking  their  eyes  away  from  the 
screen  to  view  the  UAV  directly  is  no  longer  a  detriment  to  their  eyesight.  In  addition,  since  both  video  and  map  data  are 
available  on  the  same  screen  there  is  no  need  to  de-hood  to  view  the  map;  a  simple  button  click  suffices.  Laptops  that  are 
compatible  with  night  vision  goggles  are  available  so  night  time  covert  operations  are  now  possible  as  well. 


Figure  4.  MOCU  screenshot  with  a  map  background.  Note  that  other  than  the  background,  the  display  is  the 
same  as  that  shown  in  the  video  screenshot  above. 


3.2  Other  user  interface  features 

Several  other  usability  improvements  have  been  made,  including: 

•  Single  button  click  to  establish  a  loiter  point 

•  At  most  two  touches  (or  mouse  clicks)  to  change  from  any  camera  mode  or  zoom  level  to  any  other  mode  or 
zoom  level 

•  The  altitude  command  can  be  changed  in  all  autopilot  modes  (including  NAV)  via  the  throttle  control.  The 
altitude  command  is  displayed  graphically  on  the  altitude  tape. 

•  Video  latency  reduction  from  400  milliseconds  to  200  milliseconds.  This  may  be  helpful  in  establishing  more 
precise  loiter  points. 

•  Color  coding  is  used  to  indicate  common  GUI  features.  For  example,  autopilot-related  items  such  as  UAV 
mode,  waypoints,  and  commands  are  magenta,  while  video-related  items  are  yellow. 


3.3  Mission  planning  improvements 

As  previously  mentioned  there  are  some  eccentricities  with  the  waypoint  altitude  display  of  the  FalconView-based 
mission  planner  of  the  stock  GCS.  The  equivalent  waypoint  altitude  planner  for  MOCU  is  shown  in  Figure  5. 


Figure  5.  MOCU  waypoint  altitude  mission  plans  show  AGL  in  the  text  box  while  the  MSL  of  the  waypoint  is 
shown  in  the  altitude  tape  on  the  left. 

The  planner  is  split  into  two  different  types,  one  for  mission-related  operations  (waypoints  A  -  D,  the  orbit  waypoints, 
and  the  rally  altitude),  and  takeoff  and  landing.  The  screenshot  in  Figure  5  is  for  mission  planning.  The  MSL  of  each 
waypoint  can  be  seen  relative  to  the  altitude  scale  on  the  left,  but  more  importantly  the  AGL  altitude  is  shown  both 
graphically  (the  green  terrain  below  each  waypoint)  as  well  as  textually  in  a  box  below  each  waypoint.  Missions  often 
require  that  a  minimum  ground  clearance  be  maintained  which  is  easy  to  do  here,  whereas  it  is  tedious  with  the  stock 
GCS. 

Figure  6  shows  the  takeoff  and  landing  planner.  In  the  stock  GCS  the  mission  and  takeoff/landing  planners  are  all 
combined  into  one  display.  However,  MOCU  renders  the  planners  as  separate  windows  making  the  display  less 
cluttered  and  more  usable  during  these  distinct  phases  of  flight. 
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Figure  6.  Mission  planner  for  takeoff  and  landing.  For  takeoff  the  relationship  between  the  launch  point  (the 
home  icon)  and  the  first  waypoint  (A)  are  most  important,  while  for  landing  the  D,  E  and  L  waypoints  are  most 
important. 


One  last  mission  planner  difference  is  shown  in  Figure  7.  If  the  user  clicks  and  drags  along  the  right  edge  of  the 
waypoint  window  all  the  waypoints  are  locked  to  the  same  MSL  altitude.  If  the  waypoints  are  left  at  different  MSL 
altitudes  the  UAV  is  constantly  climbing  and  descending,  thus  decreasing  overall  mission  time. 


Figure  7.  MOCU  makes  it  easy  to  set  all  the  waypoints  to  the  same  MSL. 


4.  FUTURE  WORK 

Many  improvements  are  planned  in  the  near  term: 

•  Graphical  display  of  wind  speed  and  direction.  The  direction  in  particular  will  help  with  aligning  the  E  and  L 
waypoints  so  that  the  vehicle  lands  into  the  wind  to  minimize  the  possibility  of  damage  and  increase  touchdown 
performance. 

•  Graphical  range  and  bearing  from  the  home  waypoint  to  the  vehicle.  This  indicator  will  be  color  coded  red, 
yellow,  or  white  to  indicate  if  the  remaining  battery  capacity  is  sufficient  to  return  home  given  the  current  range 
and  winds  aloft. 

•  3D  fly/no  fly  zones.  MOCU  already  has  the  capability  to  draw  and  display  fly/no  fly  zones,  but  these  need  to 
take  minimum  and  maximum  altitudes  into  account.  The  altitude  extents  of  zones  will  be  depicted  on  the 
altitude  tape  and  mission  profile  displays  for  quick  reference  during  flight  and  mission  planning  stages 
respectively. 

•  MOCU  has  the  ability  to  rotate  maps  to  an  arbitrary  angle.  By  implementing  a  user  interface  control  for  this  it 
will  improve  the  operator’s  situational  awareness.  The  typical  mission  requires  flying  in  pretty  much  a  straight 
line  to  a  particular  area  then  flying  around  that  area.  By  rotating  the  map  so  the  operator  is  at  the  bottom  and  the 
desired  operational  area  is  at  the  top,  placement  of  waypoints  becomes  more  intuitive  and  situational  awareness 
can  be  more  easily  maintained. 

•  A  camera  pointing  indicator  (CPI)  will  be  added  to  the  video  display.  This  will  show  in  the  video  the  location 
the  vehicle  is  currently  being  commanded  toward  (for  waypoints)  or  circling  (for  loiter).  In  addition,  the 
operator  will  be  able  to  drag  this  icon  to  the  desired  point.  This  should  significantly  ease  the  difficult  job  of 
establishing  the  desired  loiter  point. 


•  Telestrator-like  (aka  “John  Madden”)  annotations  to  both  the  map  and  video  screens.  This  is  a  feature  many 
users  have  requested,  which  would  allow  them  to  drop  points  on  the  screen  and  draw  lines  to  make  notes  or 
communicate  to  other  operators  desired  actions.  In  addition  these  annotations  can  be  used  to  make  range, 
distances  and  angular  measurements  on  both  the  video  and  map  screens. 

•  Users  will  be  shown  how  the  MOCU-based  GCS  operates  and  their  feedback  will  be  used  to  improve  the 
system  or  add  desired  features. 

•  User  performance  will  be  measured  using  both  a  simulator  and  actual  flights.  This  will  allow  a  direct  usability 
comparison  between  the  stock  and  MOCU  GCSs. 

5.  SUMMARY 

The  stock  GCS  for  flying  the  Raven-class  of  UAVs  is  compact  and  relatively  easy  to  learn.  However,  it  has  some 
drawbacks: 

•  Two  person  operation  (preferred,  though  not  required) 

•  Two  distinct,  dissimilar  user  interfaces  to  achieve  full  vehicle  control  and  mission  planning 

•  Poor  situational  awareness  due  to  the  need  to  use  a  hood  to  view  the  hand  controller  display 

•  Cryptic  displays  due  to  character-oriented  graphics 

A  MOCU-based  software  GCS  has  been  developed  that  addresses  all  these  shortcomings  as  well  as  additional  usability 
and  safety  improvements.  MOCU  allows  a  single  user  to  easily  control  the  UAV  for  the  entire  mission  including  launch, 
execution,  and  landing  (either  manually  or  automatically).  Because  everything  is  done  through  a  single  user  interface 
and  single  display  there  is  no  need  to  switch  from  the  hand  controller  to  the  laptop  and  back,  eliminating  the  risk  of 
disorientation  caused  by  lighting  differences. 
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